In communication networks such as those based on Long Term Evolution (LTE) as specified by the Third Generation Partnership Project (3GGP), there are certain data layer functions designed for mass communication with a large number of wireless devices, commonly referred to as “user equipments” (UEs). Some data layer functions are designed for peer-to-peer control of transport channels and for mapping between transport channels and logical channels. Examples of such functions include those used by the Radio Resource Control (RRC) protocol.
According to the Evolved Packet System (EPS) defined by the 3GPP LTE architecture, the radio access network is referred to as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN includes base stations, referred to as eNodeBs (eNBs) that provide E-UTRA user-plane and control-plane protocol terminations towards the UEs. User-plane protocol examples include Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and Physical Layer (PHY), while control-plane protocol examples include RRC.
The eNBs are connected by an “S1” interface to a core network, which is referred to as an Evolved Packet Core (EPC). More specifically, the eNBs have S1 connections to a Mobility Management Entity (MME), through an S1-MME interface and to a Serving Gateway (S-GW), through an S1-U interface. Upon request from an MME, an eNB performs an E-RAB to radio bearer mapping and establishes a Data Radio Bearer and allocates the required resources on the air interface, referred to as the “Uu” interface. The eNB also sets up a logical channel for the UE and allocates it to a transport channel. These operations involve the MAC layer.
3GPP specifies the E-UTRAN MAC protocol as a sublayer of layer 2. Functions of the MAC sublayer are performed by MAC entities in the UE and in the E-UTRAN. For a MAC entity configured at the eNB, there is a peer MAC entity configured at the UE and vice versa.
A mapping of logical channels to transport channels at the MAC sublayer is configured by RRC signaling. There is one Logical Channel Identifier (LCD) field for each MAC service data unit (SDU) included in the corresponding MAC protocol data unit (PDU). The LCID field size is 5 bits, where the value 00000 is reserved for CCCH and the value 11111 is reserved for padding. The LCID for the Downlink Shared Channel (DL-SCH) uses the range 11010-11110 for MAC Control Elements (MAC CEs). A MAC CE is an explicit MAC in-band control message. The range 01011-11001 is reserved for future needs within the framework of the controlling standard. Similarly, the LCID for the Uplink Shared Channel (UL-SCH) uses the range 11000-11110 for explicit MAC in-band control, while the range 01100-10111 is reserved for future needs within the standard.
There is a relatively scarce range of LCID values within the predefined set(s) of LCID values. Moreover, the standard tightly controls the meaning and use of the LCID values. As a general proposition, conformance to these default meaning or mappings is required for proper operation between the network and the wireless devices. Moreover, if one wishes to deviate from or expand these default mappings, standardizing new LCIDs for MAC control or other purposes is a slow, cumbersome process.
Non-standard UEs that need to communicate their non-compatibility with the standard to a standardized mobile communications network need to send non-standard messages to the network. An example of such a non-standard message may be an identifier for a non-standard UE class needed for the network to handle the UE properly or in an optimized way.
To avoid a malfunction of the network, such messages should not be sent unless the UE knows that the network can understand the message. It is therefore necessary that the network can signal support of the non-standard UE. There may also be a need for the network to provide other non-standard messages to a non-standard UE.
In E-UTRA both the S1 and the X2 interfaces allow for the inclusion of proprietary messages. However, the protocols for RRC, MAC, and physical layer protocols do not support proprietary messages. One way to provide non-standard messages in RRC or MAC is to use reserved bits or bit sequences. An alternative is to apply alternate use of a standardized Logical Channel Identity (LCID) in a MAC subheader.